1. The Field of the Invention
The present invention relates to the interaction between software components in the user mode of a computer operating system and software components in the kernel mode of a computer operating system. More specifically, the present invention relates to the proxy of software components in the kernel mode of a computer operating system by software components in the user mode of a computer operating system.
2. The Prior State of the Art
Although computers were once a rather obscure oddity used primarily by scientists, today computers have become an integral part of mainstream society. Almost daily, computers are changing the way that many people live, work, and play. The widespread proliferation of computers has opened up vast new uses and applications that were unheard of only a few short years before. Today, computers are not only a powerful tool used by many businesses, but also a source of recreation and enjoyment for millions.
As computers have evolved and have been applied to an ever increasing array of uses, they have also become more powerful, and sophisticated. Computers today have complex operating systems that provide a robust environment for various application programs and intuitive user interfaces. Such operating systems normally have different operational levels or "modes," depending on the level of sophistication of the operating system and the security features that are implemented by the operating system. For example, normal application programs typically run at the lowest priority and have a full complement of security devices in place to prohibit interference with other applications, or with other layers of the operating system. Hardware and other services provided by the operating system are only accessed through controlled interfaces or mechanisms which limit the ability of a single user application to "crash" the system. This lowest priority mode is generally referred to as "user" mode and is the mode that most computer users are familiar with.
In operating systems that provide more than one layer or mode, applications are typically not permitted to directly access computer hardware. The operating system, rather, provides interfaces through which an application program in user mode may access hardware or other services provided by the operating system. Thus, a layer of software typically exists on top of computer hardware in the system. This layer of software is typically referred to as a driver or filter.
Software drivers are normally built to control hardware and provide an interface that can be used to control or access the hardware. Drivers are typically very closely linked to the hardware components they control. For this reason, it is generally desirable to allow drivers to run in a mode with very little overhead. When drivers interface with hardware, they also typically perform many time critical functions. For example, when a driver writes data onto a mass storage device, the driver must ensure that the mass storage device always has sufficient data available to permit the data to be written to the mass storage device without large delays.
Because of the close integration of drivers with their associated hardware and because of the time critical nature of the tasks that many drivers perform, drivers typically run in an operating system mode that has a much higher priority and much lower security protection. This mode is generally referred to as "kernel" mode. Because of the few security protections available in kernel mode, software components running in kernel mode are typically restricted to the most trusted software components. Such software components typically must be thoroughly tested and behave in ways that are absolutely predictable.
Because the general concept of a software driver contemplates controlling specific hardware or providing specific services to user mode applications, drivers are normally developed in isolation from one another and provided by a hardware manufacturer or an operating system provider. For example, software drivers providing a particular type of I/O service associated with an add-in hardware card through a device interface need not communicate with, nor know the existence of, any other driver.
As previously discussed, today, computers are not only a powerful tool used by many businesses, but also a source of recreation and enjoyment for millions. One application area that has been opened up by newer, more powerful personal computers, has been the area of multimedia. Multimedia typically requires processing a stream of data using a sequence of processing functions. The data typically consists of digital samples representing sound or video, and the processing blocks or "filters" may include decompression processing for compressed data, special effects processing, transforms, scaling, rendering processing to convert digital data into analog signals, etc. Processing architectures which connect a series of different filters, each performing a particular function on a given item of data before passing the item of data onto another filter, are typically referred to as streaming architectures. The connected sequence of filters is sometimes referred to as a filter graph.
Referring now to FIG. 1, an example system is presented for rendering a stream of sound data from a disk drive so that it may be heard through the speaker according to a prior art model. An amount of data is stored on disk 20, representing sound in the form of digitized samples. Alternatively, the source of the sound data stream may be digitized information coming from a phone line, digitized information from a network, or other communication packets or sources known in the art.
A kernel mode disk driver 22, retrieves data from disk 20 under the control of a user mode reader process 24. Reader process 24 will interact with disk driver 22 using a standard I/O control interface of the operating system and will cause the compressed sound data to be read from disk 20. As data is retrieved from disk 20, it is typically placed in buffers allocated in user mode as part of the user mode address space.
When data is retrieved from disk 20 as described above, reader 24 passes the data to decompressor 28, which will decompress the data and prepare the data for further processing. In the example illustrated in FIG. 1, this step is performed entirely in user mode. This subjects the decompression step to the lower priority processing of user mode and also provides the safety mechanisms attendant with user mode execution.
After decompressor 28 has decompressed the data, the data is passed to effects component 30 will operate on the data to provide some special effect. In the example illustrated in FIG. 1, effects component 30 has an accompanying effects filter 32 operating in kernel mode. Furthermore, effects filter 32 may utilize effects processor 34 or may perform the desired processing entirely in software. In order to access effects filter 32, effects component 30 will use the system I/O control mechanism to transfer data and control to effects filter 32. This results in a kernel mode/user mode boundary transition in order to utilize effects filter 32. Effects filter 32 will utilize effects processor 34 as appropriate for the function and data presented.
After control and data is transferred from effects filter 32 back to effects component 30, the data is transferred to sound rendering block 36. Sound rendering block 36 will transfer control and data to sound rendering driver 38. This causes another mode transition as the kernel mode/user mode boundary is crossed. Sound rendering driver 38 in turn controls sound card 40 in order to render the data, as processed and filtered, as sound through speaker 42.
Operation of the filter graph including reader 24, decompressor 28, effects component 30, and sound rendering block 36 may be under the control or direction of a client or controlling process. In FIG. 1, such a controlling process is illustrated by controlling agent 26. Controlling agent 26 manages the different components in order to effectuate the rendering of sound data. Controlling agent 26 may include dynamic graph building in order to construct the filter graph illustrated in FIG. 1. Such a dynamic graph building capability may allocate software components dynamically in order to provide custom filtering or dynamic rearranging of processing paths as designated by an end user.
Several observations can be made regarding the prior art model of FIG. 1. First, the filter graph is constructed and executes largely or wholly within user mode. While such a mode provides robust error checking and security, the low priority of execution in user mode and the attendant delays may cause problems. For example, when rendering audio or video data, it is generally highly desirable to play the music or video at a constant or nearly constant speed. This requires careful attention to the delays encountered in user mode. Significant efforts have been expended in prior art models to ensure a steady and even flow of data through a user mode filter graph. However, problems still exist and there is much room for improvement. It would, therefore, be highly desirable to provide uniform rendering of a data stream without concern for the low priority execution and attendant delays of user mode.
Another observation that can be made from the architecture presented in FIG. 1, is that the rendering of data may require a number of mode transitions. Since each mode transition introduces an element of delay and requires orchestration by the operating system, it would be highly desirable to minimize or eliminate mode transitions while not sacrificing the higher priority execution that occurs in kernel mode. Presently, no technology exists that allows these goals to be achieved. Furthermore, it would be highly desirable to allow all these capabilities to be met while not sacrificing the ability of a controlling agent operating in user mode to quickly and effectively configure filter graphs to achieve a desired sequence of processing.